Controlling content modifications by enforcing one or more constraint links

ABSTRACT

Embodiments of the present disclosure include systems and methods for controlling modification of a data file that is accessed by multiple components of an application platform. The method for controlling modification of a data file includes: preparing a link constraint data that includes information of a data file and a component of an application platform, the component being associated with the data file; preparing an alert data that includes information of the data file and a person having a permission to modify the data file; responsive to an attempt of a user to modify the data file, retrieving the information of the component from the link constraint data and the information of the person from the alert data; and sending a notice of the attempt to at least one of the person and the user.

A. TECHNICAL FIELD

The present invention relates to management of data for an application platform, more particularly, to systems and methods for controlling modifications of data that is accessed by multiple components of an application platform.

B. DESCRIPTION OF THE RELATED ART

SharePoint® software (hereinafter, “SP”) is a popular web application platform that organizations use for intranet sites as well as for internal and external collaboration. SP includes SharePoint Lists® (hereinafter, “SP lists”) and SharePoint Consumers® software (hereinafter, “SP consumers” or “SP components”). SP lists are used to manage information and contain data of various types, such as, contracts, discussion board, calendar, sales, tasks or custom. For example, FIG. 1 shows a SP list 100 that contains the information of sales by employees. The Sales list 100 may have multiple fields (i.e., columns), such as employee name 102 a, department 102 b, age 102 c, and amounts of sale 102 d made by the employees.

Each SP list may be access by one or more SP components, where each SP component is a toolkit and has various functions, such as providing the SP users with data retrieved from the SP lists. For instance, Web Parts® software, which are the building blocks of pages that appear on a SharePoint, are SP components and may access the Sales list 100 and display the amounts of sales made by the employees in the sales department. In another example, SharePoint Workflows® software, which are SP components and pre-programmed mini-applications that streamline and automate a wide variety of business processes—from collecting signatures, feedback, or approvals for a plan or document, to tracking the current status of a routine procedure, may access the Sales list 100.

It is not uncommon that SP lists need some changes/updates. For instance, the amounts in the Sale 102 d may be updated on a regular basis. Such a change in the contents may not affect the operation of other SP components. However, if a user changes the name of the field 102 d, such as “Sale” into “Total Sales,” without knowing that the Sales list 100 is accessed by multiple SP components, the result may be that all of the SP components that access the Sale field 102 d would not work as expected. Even the users who have proper permission to change the Sales list 100 may modify the SP list without knowing how many SP components are currently using the SP list or they may think that the change is not harmful since they have permission. When a user makes improper changes to the SP list, some of the SP sites may crash, bringing negative impacts to other end users. This can not only cause a decrease in productivity, but also being a very bad reputation to the affected company.

Preventing harmful changes to the SP lists becomes a very challenging task as it is common that there are multiple persons, such as SP list creator and SP site owner, who have permission to change the SP lists. Typically, SP gives permission control to the SP list creator or SP site owner, and restricts other users from modifying the SP list. However, the SP list owner/site owner may not know which fields of the SP list are currently being used by SP components. As such, it becomes very difficult to manually add permission control, making safe changes to SP lists become unnecessarily complicated. Thus, there is a need for efficient systems and methods for automatically controlling modification of SP lists that are accessed by multiple SP components.

BRIEF DESCRIPTION OF THE DRAWINGS

References will be made to embodiments of the present disclosure, examples of which may be illustrated in the accompanying figures. These figures are intended to be illustrative, not limiting. Although the disclosure is generally described in the context of these embodiments, it should be understood that it is not intended to limit the scope of the disclosure to these particular embodiments. Items in the figures may not be to scale.

FIG. 1 shows an exemplary conventional SP list.

FIG. 2A shows a functional diagram of various elements in a SP farm according to embodiments of the present disclosure.

FIG. 2B shows a structure of an exemplary link constraint data generated by a link constraint data module according to embodiments of the present disclosure.

FIG. 2C shows a structure of an exemplary alert data generated by an alert data module according to embodiments of the present disclosure.

FIG. 3A shows a flowchart of an illustrative process for generating link constraint data according to embodiments of the present disclosure.

FIG. 3B shows a flowchart of an illustrative process for generating alert data according to embodiments of the present disclosure.

FIG. 4 shows a flowchart of an illustrative process for controlling modification of SP lists according to embodiments of the present disclosure.

FIG. 5 shows a computer system according to embodiments of the present disclosure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description, for purposes of explanation, specific details are set forth in order to provide an understanding of the disclosure. It will be apparent, however, to one skilled in the art that the disclosure can be practiced without these details. Furthermore, one skilled in the art will recognize that embodiments of the present disclosure, described below, may be implemented in a variety of ways, such as a process, an apparatus, a system, a device, or a method on a tangible computer-readable medium.

Elements/components shown in diagrams are illustrative of exemplary embodiments of the disclosure and are meant to avoid obscuring the disclosure. It shall also be understood that throughout this discussion that components may be described as separate functional units, which may comprise sub-units, but those skilled in the art will recognize that various components, or portions thereof, may be divided into separate components or may be integrated together, including integrated within a single system or component. It should be noted that functions or operations discussed herein may be implemented as components/elements. Components/elements may be implemented in software, hardware, or a combination thereof.

Furthermore, connections between components or systems within the figures are not intended to be limited to direct connections. Rather, data between these components may be modified, re-formatted, or otherwise changed by intermediary components. Also, additional or fewer connections may be used. It shall also be noted that the terms “coupled” “connected” or “communicatively coupled” shall be understood to include direct connections, indirect connections through one or more intermediary devices, and wireless connections.

Furthermore, one skilled in the art shall recognize that: (1) certain steps may optionally be performed; (2) steps may not be limited to the specific order set forth herein; and (3) certain steps may be performed in different orders; and (4) certain steps may be done concurrently.

Reference in the specification to “one embodiment,” “preferred embodiment,” “an embodiment,” or “embodiments” means that a particular feature, structure, characteristic, or function described in connection with the embodiment is included in at least one embodiment of the disclosure and may be in more than one embodiment. The appearances of the phrases “in one embodiment,” “in an embodiment,” or “in embodiments” in various places in the specification are not necessarily all referring to the same embodiment or embodiments. The terms “include,” “including,” “comprise,” and “comprising” shall be understood to be open terms and any lists that follow are examples and not meant to be limited to the listed items. Any headings used herein are for organizational purposes only and shall not be used to limit the scope of the description or the claims.

Furthermore, the use of certain terms in various places in the specification is for illustration and should not be construed as limiting. A service, function, or resource is not limited to a single service, function, or resource; usage of these terms may refer to a grouping of related services, functions, or resources, which may be distributed or aggregated.

Embodiments described herein use SP as an example; however, it shall be noted that the current disclosure is not limited to use only with SP. Rather, aspects of the present disclosure may be used in other situations and with other applications in which a plurality of people can access a common set of data.

FIG. 2A shows a functional diagram of various elements in a SP farm 200 according to embodiments of the present disclosure. Here, the term SP farm refers to a collection of hardwares/softwares that together make up a SharePoint platform, i.e., SP farm collectively refers to elements in the topological space of a web application platform. FIG. 2 shows only four components of a SP farm; SP lists 202, SP components 204, a smart linker 206, and SharePoint list custom property 207. However, it should be apparent to those of ordinary skill in the art that the SP farm 200 may include other suitable number of web front-end servers, databases coupled to the front-end servers and software programs running on the servers.

In embodiments, the smart linker 206 is coupled to the SP lists 202, SP components 204, and SP list custom property 207. SP lists 202 are used to manage information and contain data of various types. In FIG. 2A, only four SP lists (i.e., calendar 202 a, Sales 202 b, discussion board 202 c, and tasks 202 d) are shown for brevity. However, it should be apparent to those of ordinary skill in the art that other suitable types of lists can be included in the SP lists 202. The SP lists 202 may be accessed by one or more SP components 204, where each SP component may be a toolkit that a user may drag into an SP page and provides the SP users with data retrieved from the SP lists 202. In FIG. 2A, only three SP components (i.e., web parts 204 a, workflow 204 b and infopath 204 c) are shown, even though other suitable types of components (consumers) can be included in the SP components 204.

As depicted in FIG. 2A, the smart linker 206 includes a link constraint data module 206 a. FIG. 2B shows a structure of an exemplary link constraint data 208 generated by a link constraint data module 206 a according to embodiments of the present disclosure. As depicted, the link constraint data module 206 a generates and stores the link constraint data 208 into the SharePoint list custom property 207.

FIG. 3A shows a flowchart 300 of an illustrative process for generating link constraints between SP lists 202 and SP components 204 according to embodiments of the present disclosure. At step 301, the link constraint data module 206 a scans a SP farm to find the SP components includes in the SP farm. In one embodiment, the link constraint data module 206 a may scan the entire portion of the SP farm. In another embodiments, the link constraint data module 206 a may scan a portion of the SP farm, more specifically, the SP site collections of a web application supported by the SP farm. Hereinafter, the term SP farm refers to a fraction of or the entire portion of the SP farm that the smart link 206 is allowed to scan.

At steps 302 and 304, the link constraint data module 206 a selects one of the scanned SP components and parses the properties of the selected SP component to collect information of the SP lists and/or fields associated with the selected SP component. Then, using the collected information, the link constraint data module 206 a generates link constraint data at step 306. As depicted in FIG. 2B, the link constraint data 208 may include information of an SP list 208 a, a field 208 b of the SP list and the name\path 208 c of an SP component associated with the SP list and field. In embodiments, the Sales list 202 b may have the same data structure as the Sales list 100 in FIG. 1 and the web part 204 a may retrieve the data stored in the Sale field of the Sales list 202 b. Also, in embodiments, the value_1 may have the format of the URL_of_list#name_of_list, the value_2 may be the name of the field, and the value_3 may have the format of URL_of_component#name_of_component#componentID. In those embodiments, the value_1 is a text string “URL_of_Sales#Sales” and the value_2 is a text string “Sale” and the value_3 is a text string that includes the URL of web part 204, the name of the web part, and the ID of the web part. Here, the terms URL and ID refer to uniform-resource-locator and identification, respectively.

At step 306, the link constraint data 208 is stored in a data storage, such as SharePoint list custom property 207. Then, at step 308, the link constraint data module 206 a checks if there is any SP component to be parsed in the SP farm. If the answer to the step 308 is positive, the process proceeds to the step 302. Otherwise, the process ends at the step 310.

FIG. 2C shows a structure of an exemplary alert data 210 generated by an alert data module 206 b according to embodiments of the present disclosure. FIG. 3B shows a flowchart 330 of an illustrative process for generating alert data 210 according to embodiments of the present disclosure. At step 332, the alert data module 206 b scans a SP farm to find SP lists includes in the SP farm. At steps 334 and 336, the alert data module 206 b selects one of the SP lists and parses the properties of the selected SP list to collect the information of at least one person who has permission to modify the SP list, such as the creator of the SP list or SP site owner. Also, the alert data module 206 b accesses an authentication database, such as Active Directory® software, to get the contact information, such as email address, of the person. Then, at step 338, using the information of the person, the alert data module 206 b generates alert data 210 and stores the alert data into a data storage, such as SP list custom property 207. In embodiments, the alert data has the structure as shown in FIG. 2C. In embodiments, the value_4 of the list 210 a is similar to the value_1 in FIG. 2B, i.e., the value_4 is a text string that includes the URL of the SP list and name of the SP list while the value_5 includes the email address of the person who has the permission.

Then, at step 340, the alert data module 206 b checks if there is any SP list to be parsed in the SP farm. If the answer to the step 340 is positive, the process proceeds to the step 334. Otherwise, the process ends at the step 342.

FIG. 4 shows a flowchart 400 of an illustrative process for controlling modification of SP lists according to embodiments of the present disclosure. When a user attempts to modify a SP list, the custom validator 206 c in FIG. 2A gets information of the user at step 402. Then, at step 404, the custom validator 206 c gets the information of SP components associated with the SP list and information of the person(s) who has the permission to modify the SP list from a database, such as the SP list custom property 207. In embodiments, the custom validator 206 c also gets the information of the list creator, the list owner, the site owner. Hereinafter, the term controllers collectively refer to one or more of a list creator, a list owner, a site owner, or others with permission to modify the SP list. Next, at step 406, the custom validator 206 c sends the information of the SP components to the user so that the user is warned of the potential harm that his modification may cause to the SP components. In embodiments, at step 406, the custom validator 206 c does not allow the user to modify the SP list, i.e., the custom validator 206 c prevents the user from modifying the SP list. At step 408, the custom validator 206 c sends a notice of the attempt to the controllers. In embodiments, the notice may include various warning signals, such as the information of the user, the type of attempt, the name of list/field, the list of SP components that may be affected by the modification, or any combination thereof. In embodiments, the process 400 is performed in real time.

It is noted that the smart linker 206 may be used in other suitable application platforms, such as Lotus Notes® software, that are similar to the SharePoint® software, i.e., the smart linker 206 may be used to prevent harmful modification of data files that are accessed by multiple consumers/components in the other application platforms. In the present document, the SP lists 202 and SP components 204 are used as exemplary data files/structures and multiple consumers that access the data files/structures, respectively. As such, the SP lists 202 and SP components 204 should be interpreted as data files/structures and one or more consumers that access the data files/structures in an application platform that provides the functions similar to SharePoint® software.

As discussed above, the smart linker 206 prevents potentially harmful modification of a SP list 202 by establishing a link constraint between the SP list and SP components 204 that access the SP list. When a user wants to modify, change, or delete an SP list, the smart linker 206 automatically sends alerts to persons with permission to modify the SP list (such as SP list creator and SP site owner) as well as the user so that they are warned of the potential harm of the attempt and take proper actions to prevent the attempt or assist the user to complete the modification in a safe manner.

In embodiments, one or more computing system may be configured to perform one or more of the methods, functions, and/or operations presented herein. Systems that implement at least one or more of the methods, functions, and/or operations described herein may comprise an application or applications operating on at least one computing system. The computing system may comprise one or more computers and one or more databases. The computer system may be a single system, a distributed system, a cloud-based computer system, or a combination thereof.

It shall be noted that the present disclosure may be implemented in any instruction-execution/computing device or system capable of processing data, including, without limitation phones, laptop computers, desktop computers, and servers. The present disclosure may also be implemented into other computing devices and systems. Furthermore, aspects of the present disclosure may be implemented in a wide variety of ways including software (including firmware), hardware, or combinations thereof. For example, the functions to practice various aspects of the present disclosure may be performed by components that are implemented in a wide variety of ways including discrete logic components, one or more application specific integrated circuits (ASICs), and/or program-controlled processors. It shall be noted that the manner in which these items are implemented is not critical to the present disclosure.

Having described the details of the disclosure, an exemplary system 500, which may be used to implement one or more aspects of the present disclosure, will now be described with reference to FIG. 5. Each client/server in FIG. 1 includes one or more components in the system 500. As illustrated in FIG. 5, system 500 includes a central processing unit (CPU) 501 that provides computing resources and controls the computer. CPU 501 may be implemented with a microprocessor or the like, and may also include a graphics processor and/or a floating point coprocessor for mathematical computations. System 500 may also include a system memory 502, which may be in the form of random-access memory (RAM) and read-only memory (ROM).

A number of controllers and peripheral devices may also be provided, as shown in FIG. 5. An input controller 503 represents an interface to various input device(s) 504, such as a keyboard, mouse, or stylus. There may also be a scanner controller 505, which communicates with a scanner 506. System 500 may also include a storage controller 507 for interfacing with one or more storage devices 508 each of which includes a storage medium such as magnetic tape or disk, or an optical medium that might be used to record programs of instructions for operating systems, utilities and applications which may include embodiments of programs that implement various aspects of the present disclosure. Storage device(s) 508 may also be used to store processed data or data to be processed in accordance with the disclosure. System 500 may also include a display controller 509 for providing an interface to a display device 511, which may be a cathode ray tube (CRT), a thin film transistor (TFT) display, or other type of display. System 500 may also include a printer controller 512 for communicating with a printer 513. A communications controller 514 may interface with one or more communication devices 515, which enables system 500 to connect to remote devices through any of a variety of networks including the Internet, an Ethernet cloud, an FCoE/DCB cloud, a local area network (LAN), a wide area network (WAN), a storage area network (SAN) or through any suitable electromagnetic carrier signals including infrared signals.

In the illustrated system, all major system components may connect to a bus 516, which may represent more than one physical bus. However, various system components may or may not be in physical proximity to one another. For example, input data and/or output data may be remotely transmitted from one physical location to another. In addition, programs that implement various aspects of this disclosure may be accessed from a remote location (e.g., a server) over a network. Such data and/or programs may be conveyed through any of a variety of machine-readable medium including, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store or to store and execute program code, such as application specific integrated circuits (ASICs), programmable logic devices (PLDs), flash memory devices, and ROM and RAM devices.

Embodiments of the present disclosure may be encoded upon one or more non-transitory computer-readable media with instructions for one or more processors or processing units to cause steps to be performed. It shall be noted that the one or more non-transitory computer-readable media shall include volatile and non-volatile memory. It shall be noted that alternative implementations are possible, including a hardware implementation or a software/hardware implementation. Hardware-implemented functions may be realized using ASIC(s), programmable arrays, digital signal processing circuitry, or the like. Accordingly, the “means” terms in any claims are intended to cover both software and hardware implementations. Similarly, the term “computer-readable medium or media” as used herein includes software and/or hardware having a program of instructions embodied thereon, or a combination thereof. With these implementation alternatives in mind, it is to be understood that the figures and accompanying description provide the functional information one skilled in the art would require to write program code (i.e., software) and/or to fabricate circuits (i.e., hardware) to perform the processing required.

It shall be noted that embodiments of the present disclosure may further relate to computer products with a non-transitory, tangible computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind known or available to those having skill in the relevant arts. Examples of tangible computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store or to store and execute program code, such as application specific integrated circuits (ASICs), programmable logic devices (PLDs), flash memory devices, and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an interpreter. Embodiments of the present disclosure may be implemented in whole or in part as machine-executable instructions that may be in program modules that are executed by a processing device. Examples of program modules include libraries, programs, routines, objects, components, and data structures. In distributed computing environments, program modules may be physically located in settings that are local, remote, or both.

One skilled in the art will recognize no computing system or programming language is critical to the practice of the present disclosure. One skilled in the art will also recognize that a number of the elements described above may be physically and/or functionally separated into sub-modules or combined together.

It will be appreciated to those skilled in the art that the preceding examples and embodiment are exemplary and not limiting to the scope of the present disclosure. It is intended that all permutations, enhancements, equivalents, combinations, and improvements thereto that are apparent to those skilled in the art upon a reading of the specification and a study of the drawings are included within the true spirit and scope of the present disclosure. 

What is claimed is:
 1. A method for controlling modification of a data file associated with multiple components of an application platform, comprising: preparing a link constraint data that includes information of a data file and a component of an application platform, the component being associated with the data file; preparing an alert data that includes information of the data file and controllers of the data file; responsive to an attempt of a user to modify the data file: retrieving the information of the component from the link constraint data and the information of the controllers from the alert data; and not allowing the user to modify the data file; and sending a notice of the attempt to modify the data file to one or more of the controllers and the user.
 2. A method as recited in claim 1, wherein the step of preparing a link constraint data comprises: scanning the application platform to find the component included in the application platform; parsing properties of the component to collect the information of the data file; generating the link constraint data using the information of the data file and component; and storing the link constraint data in a database.
 3. A method as recited in claim 1, wherein the step of preparing an alert data comprises: scanning the application platform to find the data file included in the application platform; parsing properties of the data file to collect the information of the controllers; generating the alert data using the information of the data file and controllers; and storing the alert data in a database.
 4. A method as recited in claim 1, wherein the data file includes at least one field and the link constraint data includes a uniform resource location (URL) path of the data file, a name of the field, and a name of the component.
 5. A method as recited in claim 1, wherein the alert data includes a uniform resource location (URL) path of the data file and a contact information of the controllers.
 6. A system that controls modification of a data file associated with multiple components of an application platform, comprising: one or more processors; and a non-transitory computer-readable medium or media comprising one or more sequences of instructions which, when executed by the one or more processors, causes steps to be performed comprising: preparing a link constraint data that includes information of a data file and a component of an application platform, the component being associated with the data file; preparing an alert data that includes information of the data file and controllers of the data file; responsive to an attempt of a user to modify the data file: retrieving the information of the component from the link constraint data and the information of the controllers from the alert data; and not allowing the user to modify the data file; and sending a notice of the attempt to modify the data file to one or more of the controllers and the user.
 7. A system as recited in claim 6, wherein the step of preparing a link constraint data comprises: scanning the application platform to find the component included in the application platform; parsing properties of the component to collect the information of the data file; generating the link constraint data using the information of the data file and component; and storing the link constraint data in a database.
 8. A system as recited in claim 6, wherein the step of preparing an alert data comprises: scanning the application platform to find the data file included in the application platform; parsing properties of the data file to collect the information of the controllers; generating the alert data using the information of the data file and controllers; and storing the alert data in a database.
 9. A system as recited in claim 6, wherein the data file includes at least one field and the link constraint data includes a uniform resource location (URL) path of the data file, a name of the field, and a name of the component.
 10. A system as recited in claim 6, wherein the alert data includes a uniform resource location (URL) path of the data file and a contact information of the controllers.
 11. A smart linker that controls modification of a data file associated with multiple components of an application platform, comprising: a link constraint data module that prepares a link constraint data, the link constraint data includes information of a data file and a component of an application platform, the component being associated with the data file; a alert data module that prepares an alert data, the alert data includes information of the data file and controllers of the data file; and a custom validator that, in responsive to an attempt of a user to modify the data file, retrieves the information of the component from the link constraint data and the information of the controllers from the alert data, prevents the user from modifying the data file and sends a notice of the attempt to one or more of the controllers and the user.
 12. A smart linker as recited in claim 11, wherein the link constraint data module performs the steps of: scanning the application platform to find the component included in the application platform; parsing properties of the component to collect the information of the data file; generating the link constraint data using the information of the data file and component; and storing the link constraint data in a database.
 13. A smart linker as recited in claim 11, wherein the alert data module performs the steps of: scanning the application platform to find the data file included in the application platform; parsing properties of the data file to collect the information of the controllers; generating the alert data using the information of the data file and controllers; and storing the alert data in a database.
 14. A smart linker as recited in claim 11, wherein the data file includes at least one field and the link constraint data includes a uniform resource location (URL) path of the data file, a name of the field, and a name of the component.
 15. A smart linker as recited in claim 11, wherein the alert data includes a uniform resource location (URL) path of the data file and a contact information of the controllers. 